银行业分布式事务的前世今生

9

星期二

2021年2月

验“金”室

事务与金融业务似乎是一对孪生兄弟，想要正确地汇款就不得不采用事务模型，以银行转账的例子来说明事务模式再合适不过了。显然银行业务与事务息息相关，而且传统的集中式部署下的事务也已经有了比较成熟的解决方案。随着互联网时代的到来，分布式、云计算、大数据等新兴技术快速发展，金融产品在当前科技创新的浪潮下也在不断更新，大量业务已经开始向服务化、分布式方向转型，由此带来的分布式事务问题也成为银行技术转型中的重点和难点。

一、传统IT架构下

银行业务分布式事务

分布式事务其实并不是一个新概念或者新问题，传统银行业务也存在分布式事务问题。很多传统银行业务均由大型IBM主机实现，一个主机可以管理多个数据库，比如说，私人账户信息存在一个单独的数据库中，对公账户信息则存在另一个数据库中。这种情况下，如果对公账户需要向私人账户汇款，那么交易涉及两个不同的数据库，如何保证这两个数据库数据的一致性，便是分布式事务所要解决的问题。

那么，银行传统IT架构如何解决分布式事务问题呢？

很显然，需要一个上层的角色来协调各个数据库的状态，这个角色就是事务管理器。除此之外，为了保证数据的一致性，还应将单个操作分为事务的执行和提交或回滚事务两个步骤，具体步骤如图1所示。

图1  两阶段提交协议

第一步

事务管理器向所有事务参与者发送请求，每个事务参与者执行各自的操作并锁定数据库资源，然后将执行结果返回给事务管理器。

第二步

事务管理器收集各个参与者的执行结果。若所有参与者都执行成功，则管理器通知参与者提交事务并释放占用的资源；如果有参与者返回失败或超时，则通知所有参与者回滚事务并释放占用的资源。

这便是两阶段提交协议，著名的XA协议就是基于此两阶段提交协议。正如上文所说，传统的银行系统往往采用IBM大型主机管理多个数据库实现，IBM开发的CICS中间件就提供对XA协议的支持来保证所有数据库的提交或回滚。

二、新形势下银行业务分布式事务

随着需求的快速迭代与业务量的激增，新形势下传统的IBM主机扩容、迭代等遇到挑战。同时随着互联网行业的快速发展，云计算、分布式和微服务技术迅速崛起，银行作为传统金融行业快速拥抱变化，积极地参与到这场IT架构变革中，大量业务不断向服务化、分布式的方向转型。

在分布式系统中，一个大型的主机系统往往被分割为多个子系统。比如上述例子中，对公账户的交易和个人账户的交易可能都在各自系统中，如果有同时涉及这两个账户的交易，那么与同一个主机下操作多个数据库有所不同，这里的交易需要操作多个系统下的数据库。如果仍然采用XA协议，事务管理器需要锁定多个系统下的数据库资源，此时网络的不可靠会成倍增加事务处理时间，产生大量数据库锁和数据不可用。

1.柔性事务与BASE理论

为了解决上述这个问题，业界提出了柔性事务的理念，其基本思想是放宽对强一致性的要求，来换取系统吞吐量的提升，但是分布式系统中所有数据副本在经过一定时间后，最终要能够达到一致的状态。基于此思想，eBay架构师Dan Prichett通过对大规模分布式系统进行实践总结出了BASE理论，即基本可用（Basically Available，分布式系统在遇到故障时，允许损失部分可用性）、软状态（Soft state，允许系统存在中间状态，且此状态不影响系统整体可用性）和最终一致性（Eventually Consistent，分布式系统中所有数据副本在经过一定时间后，最终能够达到一致的状态）。基于上述理论，业界提出SAGA、TCC、消息等新模型解决分布式事务问题。

 2.SAGA模型分布式事务

显然，两阶段提交协议的性能瓶颈在于一阶段对数据库资源的锁定，于是基于柔性事务和BASE理论可以对此进行改造，令每个子事务在执行完事务后立即提交并释放锁资源。那么，当下游交易出现异常时，必须执行其反向交易来保证数据的一致性，这种通过冲正补偿的方式来解决分布式事务的模型一般称为SAGA模型，其基本流程如图2所示。

图2  SAGA模型流程

每个分布式事务有多个参与者，每个参与者都实现其正向交易和反向补偿交易，在业务流程中执行各个参与者的正交易，当出现失败时则补偿前面已完成交易的反交易。

3.TCC模型分布式事务

还是从两阶段提交协议出发，将一阶段对资源的预留从数据库层面上升至业务层面，即通过业务检查而不是锁定数据库来预留资源，这便是TCC模型。TCC即Try、Confirm、Cancel，其基本流程如图3所示。

图3  TCC模型流程

一阶段执行Try：完成所有业务检查，预留必须业务资源；

二阶段执行Confirm：Try阶段成功后执行，不作任何业务检查，执行真正的业务逻辑，且默认Confirm阶段是不会出错的，因此此阶段作业可以异步化实现来提高性能。

二阶段执行Cancel：业务执行失败，需要回滚的情况下执行，释放Try阶段预留的业务资源。

4.消息模型分布式事务

为避免对数据库事务的争用，有时可以将一些同步阻塞的事务操作变为异步的操作，一般称为消息事务模型，该模型的特点是通过异步实现两个系统之间的解耦和并发的缓冲，其基本流程如图4表示。

图4  消息模型流程

 三、分布式事务在银行业务中的运用

随着银行业务不断向服务化、分布式方向转型，分布式事务问题越来越突出。不同的分布式事务模型各有其的特点和适用范围，不同银行业务下的分布式事务问题需要选择合适的事务模型解决。

1. SAGA模式的应用

很明显，由于SAGA正交易完成后子事务立即提交，数据立即可见，在并发场景下SAGA模型无法保证业务的隔离性。而且，对于银行业务的一些场景，比如一借多贷，一笔借款存在多笔贷记子事务，如果前面的子事务资产直接入账，则可能存在交易异常无法回滚的风险。因此，金融核心业务场景如转账汇款、理财购买并不适合使用SAGA模型。但是在银行系统中，SAGA模型适合工作流、业务流等自身隔离性强的业务，比如微黄金新用户开户、凭证式国债挂失销户等。

2. TCC模式的应用

TCC是通过业务的重新编排设计来确保交易数据访问隔离，对业务的改造相对较大，但是因为采用预留数据资源的方式，并不加锁，所以性能较优，且允许和消息模型组合使用。在银行的业务中，一般涉及转账、资金的高风险业务的分布式事务都需要采用TCC模式。

3. 消息模式的应用

消息模式很少单独使用，一般都需要配合SAGA模式或TCC模式使用。典型应用比如说贷款成功后，执行短信通知、优惠券积分等通知辅助类功能的业务以及一些针对外系统的交互。

目前，解决分布式事务问题已经成为银行IT架构转型中必不可少的一环，现阶段，往往是对模型的性能、业务改造成本、可用性等能力上做了针对性的取舍，如何根据自身业务特点探索一套成熟的解决方案，将是未来银行技术转型中的重点。

往期推荐